docs for build_id & multi-config #161
Conversation
| that allows consumers to reuse an existing package without building it again from sources. | ||
|
|
||
| The other type of information would be C/C++ build information, as include paths, library names, or | ||
| compile flags |
There was a problem hiding this comment.
It looks confusing to me. I wouldn't say that a package identifier is an information for me, the consumer.
There was a problem hiding this comment.
Well, it is printed in the conan info command, is useful information for consumers of the package, to know which binary they are actually using for a given configuration.
But, yes, I agree that the title/description could be improved.
| else: | ||
| for config in ("Debug", "Release"): | ||
| self.output.info("Building %s" % config) | ||
| self.run('cmake "%s" %s -DCMAKE_BUILD_TYPE=%s' |
There was a problem hiding this comment.
new configure/build helpers?
There was a problem hiding this comment.
Not really. The helpers use the standard cmake.command_line which depend on `sèttings.build_type`` in this case not defined. So I am manually overriding the behavior. Probably it could be wrapped in another cmake helper method.
| Package IDs | ||
| ------------ | ||
|
|
||
| package_id |
There was a problem hiding this comment.
I'm not sure about this file in the docs. Maybe all this should go to conanfile.py page and this page just explain the general why and link to conanfile.py page.
There was a problem hiding this comment.
And maybe the conanfile.py page should be splitted in several subpages. It's becoming too big.
There was a problem hiding this comment.
Nop, the conanfile_py.rst if you meant that, is just for package consumers. This is only relevant for package creators, and I think it should go inside the "Creating packages section".
No description provided.